今天打算從 RD 的角度講講下面這張圖 講不完就明天講

其實在開始這個系統之前，我有大概想了一下要講什麼，在 bottom-up 搞系統管理這幾年間，
其中一個非常困擾人的問題，就是技術選型

我可能只有 title 是資深，其實一點也不資深，只是輾轉經過了幾個團隊都剛好某種程度參與了維運，從實體機房、on-premise 的私有雲再到 AWS 的公有雲摸了一遍，甚至連 Kubernetes 都從頭架了一遍，並且順手考了 Certified Kubernetes Administrator 證照(目前在硬體廠用不到就沒再續了)

CKA lincence number: CKA-1900-002390-0100, just for the record…

明明不是專職的 IT/DevOps，卻從 RD 的角度踩了很多維運上的坑，
其中最常見的坑之一，就是接下來要提到的 技術選型

在網路資料、ChatGPT 那麼強大的時代，如果我只講 demo 怎麼架、YAML 怎麼寫，
那就失去我的本意了，那麼叫 ChatGPT 出來講就好了，
我打算講幾篇廢話，最後附上 step by step 的 how to build a demo 就打完收工
更多的是我想發表我為什麼選擇了 Ansible AWX 這個相對冷門的技術棧，
拋磚引玉的跟有興趣的大大交流一下，但畢竟是兼職維運的 RD 仔…請小力鞭

在我看來，技術選型的決定性因素就是 底層邏輯
(咦…不是部門政治嗎…)
拿維運這件事來說，
軟體自動化這種事早幾年我還能有選擇的時候就是百家爭豔，隨便提幾個

• 不用框架派：各種 shell script + python + perl + awk + sed 自己刻
• Ruby based 的 Puppet、Chef
• Python based 的 Ansible(RedHat)、SaltStack(VMWare)

基於「人生苦短，我用 Python」，再基於對 community 的觀察，最終(其實沒什麼掙扎)就秒選學習 Ansible

Life is short, you need Python

軟體自動化的底層邏輯其實就是五拍子

1. incoming request: 某個人通知你要做某件事
2. pull resources: 到處拉 repo 拉 config
3. build artifacts: 把 code 編成各種 binary，把參數結合各種模板揉成各種 config
4. push results: 把各種 output 推到該去的地方，不管是 code、config、binary...etc
5. notify status: 不管結果如何，由機器通知到負責管理的人

Ansible 可以很好的做到 2~5 的所有事情，唯獨 1，為了接收 incoming request，
你實際上需要一個 always listen 的 service，講白一點，你需要一個非常輕量的 web service，
既然都學了 Python，你當然可以自幹幾行 code，然後 python3 -m webbrowser & 就完事了，
但萬一 service 掛了，或是想查找 build flow 的 log，那不是很麻煩嗎？

再說多一點，純用 Ansible 你做不到幾件事

• 無法法 on-demand 執行任務，e.g. 收來自 SCM(Source Control Management) 的 webhook
• 沒有漂亮的 GUI 介面可以 截圖做簡報 與同事或老闆溝通
• 無法定時排程做任務，你當然很有可能有 crontab -e 可以用，但如果複雜一點的排程就很麻煩

基於上述幾點，你大概率在學完 Ansible 之後，
就會考慮 host 一下 web portal 來彌補 Ansible 的不足

今天先寫到這好了…結果架構圖一個字也沒提到…